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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


This document describes a preemption priority policy element for use 
by signaled policy based admission protocols (such as [RSVP] and 
[COPS]). 


Preemption priority defines a relative importance (rank) within the 
set of flows competing to be admitted into the network. Rather than 
admitting flows by order of arrival (First Come First Admitted) 
network nodes may consider priorities to preempt some previously 
admitted low priority flows in order to make room for a newer, high- 
priority flow. 
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1 Introduction 


Traditional Capacity based Admission Control (CAC) indiscriminately 
admits new flows until capacity is exhausted (First Come First 
Admitted). Policy based Admission Control (PAC) on the other hand 
attempts to minimize the significance of order of arrival and use 
policy based admission criteria instead. 


One of the more popular policy criteria is the rank of importance of 
a flow relative to the others competing for admission into a network 
node. Preemption Priority takes effect only when a set of flows 
attempting admission through a node represents overbooking of 
resources such that based on CAC some would have to be rejected. 
Preemption priority criteria help the node select the most important 
flows (highest priority) for admission, while rejecting the low 
priority ones. 


Network nodes which support preemption should consider priorities to 
preempt some previously admitted low-priority flows in order to make 
room for a newer, high-priority flow. 


This document describes the format and applicability of the 
preemption priority represented as a policy element in [RSVP-EXT]. 
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2 Scope and Applicability 


The Framework document for policy-based admission control [RAP] 
describes the various components that participate in policy decision 
making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI 
elements is to be simple, stateless, and light-weight such that they 
could be implemented internally within a node’s LDP (Local Decision 
Point). 


Certain base assumptions are made in the usage model for 
PREEMPTION_PRI elements: 


- They are created by PDPs 


In a model where PDPs control PEPs at the periphery of the policy 
domain (e.g., in border routers), PDPs reduce sets of relevant 
policy rules into a single priority criterion. This priority as 
expressed in the PREEMPTION_PRI element can then be communicated 
to downstream PEPs of the same policy domain, which have LDPs but 
no controlling PDP. 


- They can be processed by LDPs 


PREEMPTION_PRI elements are processed by LDPs of nodes that do not 
have a controlling PDP. LDPs may interpret these objects, forward 
them as is, or perform local merging to forward an equivalent 
merged PREEMPTION_PRI policy element. LDPs must follow the merging 
strategy that was encoded by PDPs in the PREEMPTION_PRI objects. 
(Clearly, a PDP, being a superset of LDP, may act as an LDP as 
well). 


- They are enforced by PEPs 


PREEMPTION_PRI elements interact with a node’s traffic control 
module (and capacity admission control) to enforce priorities, and 
preempt previously admitted flows when the need arises. 


3 Stateless Policy 


Signaled Preemption Priority is stateless (does not require past 
history or external information to be interpreted). Therefore, when 
carried in COPS messages for the outsourcing of policy decisions, 
these objects are included as COPS Stateless Policy Data Decision 
objects (see [COSP, COPS-RSVP]). 
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4 Policy Element Format 
The format of Policy Data objects is defined in [RSVP-EXT]. A single 
Policy Data object may contain one or more policy elements, each 


representing a different (and perhaps orthogonal) policy. 


The format of preemption priority policy element is as follows: 


A E possesens feesdae nE toa a5 5 + 
| Length (12) | P-Type = PREEMPTION_PRI | 
psszt +------ tasneeg nnna E NE aaa ta + 
| Flags | M. Strategy | Error Code | Reserved(0) | 
t------ tanmen fanme a e RE Fenne ae + 
| Preemption Priority | Defending Priority | 
pasians +------ toss aa toss sa toa ssa + 


Length: 16 bits 
Always 12. The overall length of the policy element, in bytes. 


P-Type: 16 bits 
PREEMPTION_PRI = 3 


This value is registered with IANA, see Section 7. 


Flags: 8 bits 
Reserved (always 0). 


Merge Strategy: 8 bit 


1 Take priority of highest QoS: recommended 
2 Take highest priority: aggressive 
3 Force Error on heterogeneous merge 


Reserved: 8 bits 

Error code: 8 bits 
0 NO_ERROR Value used for regular PREEMPTION_PRI elements 
1 PREEMPTION This previously admitted flow was preempted 
2 HETEROGENEOUS This element encountered heterogeneous merge 


Reserved: 8 bits 
Always 0. 


Preemption Priority: 16 bit (unsigned) 
The priority of the new flow compared with the defending priority 
of previously admitted flows. Higher values represent higher 
Priority. 
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Defending Priority: 16 bits (unsigned) 
Once a flow was admitted, the preemption priority becomes 
irrelevant. Instead, its defending priority is used to compare 
with the preemption priority of new flows. 


For any specific flow, its preemption priority must always be less 
than or equal to the defending priority. A wide gap between 
preemption and defending priority provides added stability: moderate 
preemption priority makes it harder for a flow to preempt others, but 
once it succeeded, the higher defending priority makes it easier for 
the flow to avoid preemption itself. This provides a mechanism for 
balancing between order dependency and priority. 


5 Priority Merging Issues 

Consider the case where two RSVP reservations merge: 

Fl: QoS=High, Priority=Low 

F2: QoS=Low, Priority=High 
F1+F2= F3: QoS=High, Priority=??? 
The merged reservation F3 should have QoS=Hi, but what Priority 
should it assume? Several negative side-effects have been identified 
that may affect such a merger: 
Free-Riders: 
If F3 assumes Priority=High, then Fl got a free ride, assuming high 
priority that was only intended to the low QoS F2. If one associates 
costs as a function of QoS and priority, Fl receives an "expensive" 
priority without having to "pay" for it. 


Denial of Service: 


If F3 assumes Priority=Low, the merged flow could be preempted or 
fail even though F2 presented high priority. 


Denial of service is virtually the inverse of the free-rider problem. 
When flows compete for resources, if one flow receives undeserving 
high priority it may be able to preempt another deserving flow (hence 
one free-rider turns out to be another’s denial of service). 
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Instability: 


The combination of preemption priority, killer reservation and 
blockade state [RSVP] may increase the instability of admitted flows 
where a reservation may be preempted, reinstated, and preempted again 
periodically. 


5.1 Priority Merging Strategies 


In merging situations LDPs may receive multiple preemption elements 
and must compute the priority of the merged flow according to the 
following rules: 


a. Preemption priority and defending priority are merged and computed 
separately, irrespective of each other. 


b. Participating priority elements are selected. 


All priority elements are examined according to their merging 
strategy to decide whether they should participate in the merged 
result (as specified bellow). 


c. The highest priority of all participating priority elements is 
computed. 


The remainder of this section describes the different merging 
strategies the can be specified in the PREEMPTION_PRI element. 


5.1.1 Take priority of highest QoS 


The PREEMPTION_PRI element would participate in the merged 
reservation only if it belongs to a flow that contributed to the 
merged QoS level (i.e., that its QoS requirement does not constitute 
a subset another reservation.) A simple way to determine whether a 
flow contributed to the merged QoS result is to compute the merged 
QoS with and without it and to compare the results (although this is 
clearly not the most efficient method). 


The reasoning for this approach is that the highest QoS flow is the 
one dominating the merged reservation and as such its priority should 
dominate it as well. This approach is the most amiable to the 
prevention of priority distortions such as free-riders and denial of 
service. 


This is a recommended merging strategy. 
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5.1.2 Take highest priority 
All PREEMPTION_PRI elements participate in the merged reservation. 
This strategy disassociates priority and QoS level, and therefore is 
highly subject to free-riders and its inverse image, denial of 


service. 


This is not a recommended method, but may be simpler to implement. 


5.1.3 Force error on heterogeneous merge 


A PREEMPTION_PRI element may participate in a merged reservation only 
if all other flows in the merged reservation have the same QoS level 
(homogeneous flows). 


The reasoning for this approach assumes that the heterogeneous case 
is relatively rare and too complicated to deal with, thus it better 
be prohibited. 


This strategy lends itself to denial of service, when a single 
receiver specifying a non-compatible QoS level may cause denial of 
service for all other receivers of the merged reservation. 


Note: The determination of heterogeneous flows applies to QoS level 
only (FLOWSPEC values), and is a matter for local (LDP) definition. 
Other types of heterogeneous reservations (e.g. conflicting 
reservation styles) are handled by RSVP and are unrelated to this 
PREEMPTION_PRI element. 


This is a recommended merging strategy when reservation homogeneity 
is coordinated and enforced for the entire multicast tree. It is more 
restrictive than Section 5.1.1, but is easier to implement. 


5.2 Modifying Priority Elements 


When POLICY_DATA objects are protected by integrity, LDPs should not 
attempt to modify them. They must be forwarded as-is or else their 
security envelope would be invalidated. In other cases, LDPs may 
modify and merge incoming PREEMPTION_PRI elements to reduce their 
size and number according to the following rule: 


Merging is performed for each merging strategy separately. 
There is no known algorithm to merge PREEMPTION_PRI element of 


different merging strategies without loosing valuable information 
that may affect OTHER nodes. 
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- For each merging strategy, the highest QoS of all participating 
PREEMPTION_PRI elements is taken and is placed in an outgoing 
PREEMPTION_PRI element of this merging strategy. 


- This approach effectively compresses the number of forwarded 
PREEMPTION_PRI elements to at most to the number of different 
merging strategies, regardless of the number of receivers (See the 
example in Appendix A.2). 


6 Error Processing 


A PREEMPTION_PRI error object is sent back toward the appropriate 
receivers when an error involving PREEMPTION_PRI elements occur. 


PREEMPTION 


When a previously admitted flow is preempted, a copy of the 
preempting flow’s PREEMPTION_PRI element is sent back toward the PDP 
that originated the preempted PREEMPTION_PRI object. This PDP, having 
information on both the preempting and the preempted priorities may 
construct a higher priority PREEMPTION_PRI element in an effort to 
re-instate the preempted flow. 


Heterogeneity 


When a flow Fl with Heterogeneous Error merging strategy set in its 
PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI 

element is sent back toward receivers with the Heterogeneity error 

code set. 


7 IANA Considerations 
Following the policies outlined in [IANA-CONSIDERATIONS], Standard 
RSVP Policy Elements (P-type values) are assigned by IETF Consensus 
action as described in [RSVP-EXT]. 
P-Type PREEMPTION_PRI is assigned the value 3. 


8 Security Considerations 


The integrity of PREEMPTION_PRI is guaranteed, as any other policy 
element, by the encapsulation into a Policy Data object [RSVP-EXT]. 


Further security mechanisms are not warranted, especially considering 
that preemption priority aims to provide simple and quick guidance to 
routers within a trusted zone or at least a single zone (no zone 
boundaries are crossed). 


Herzog Standards Track [Page 8] 


RFC 2751 Signaled Preemption Priority Policy Element January 2000 


9 References 


[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy 
Control", RFC 2750, January 2000. 


[COPS-RSVP ] Boyle, J., Cohen, R., Durham, D., Herzog, S., 
Raja, R. and A. Sastry, "COPS usage for RSVP", 
RFC 2749, January 2000. 


[RAP ] Yavatkar, R., et al., "A Framework for Policy 
Based Admission Control", RFC 2753, January 
2000. 

[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., 


Raja, R. and A. Sastry, "The COPS (Common Open 
Policy Service) Protocol", RFC 2748, January 


2000. 
[RSVP ] Braden, R., ed., et al., “Resource ReSerVation 
Protocol (RSVP) - Functional Specification", 


RFC 2205, September 1997. 


[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 
Writing an IANA Considerations Section in 
RFCs", BCP 26, RFC 2434, October 1998. 


10 Author Information 
Shai Herzog 
IPHighway, Inc. 

55 New York Avenue 


Framingham, MA 01701 


Phone: (508) 620-1141 
EMail: herzog@iphighway.com 


Herzog Standards Track [Page 9] 


RFC 2751 Signaled Preemption Priority Policy Element January 2000 


Appendix A: Example 


The following examples describe the 
elements as well as the translation 
elements. 


A.1 Computing Merged Priority 


QoS=Low (Pr=9, St=Error) 


Example 1: Merging preemption 


computation of merged priority 
(compression) of PREEMPTION_PRI 


(Pr=3, St=Highest QoS) 
QoS=Low (Pr=4, St=Highest PP) 


(Pr=7, St=Highest QoS) 


priority elements 


Example one describes a multicast scenario with one sender and four 
receivers each with each own PREEMPTION_PRI element definition. 


rl, r2 and r3 merge in B. The resulting priority is 4. 


Reason: The PREEMPTION_PRI of r3 doesn’t participate (since r3 is not 


contributing to the merged QoS) and 
the PREEMPTION_PRI from rl and r2. 


the priority is the highest of 


rl, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 


doesn’t participate because its own 


QoS=Low is incompatible with the 


other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to 
r4 telling it that its PREEMPTION_PRI element encountered 


heterogeneity. 
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A.2 Translation (Compression) of Priority Elements 


Given this set of participating PREEMPTION_PRI elements, the 
following compression can take place at the merging node: 


From: 
(Pr=3, St=Highest QoS) 
(Pr=7, St=Highest QoS) 
(Pr=4, St=Highest PP) 
(Pr=9, St=Highest PP) 
(Pr=6, St=Highest PP) 
To: 
(Pr=7, St=Highest QoS) 
(Pr=9, St=Highest PP) 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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